Learning Objectives

After completing this lesson, you’ll be able to:

Instructions

In this lesson, you will:

Resources

Creating Multiple Streams of Data

FME workspaces send data from left to right across the canvas from reader feature types to writer feature types. The simplest workspace has only one “stream” of data: features are read in, processed the same way, and then written out. However, workspaces can have multiple data streams, splitting and merging features as required. 

Did you find the correct transformer in the last exercise?

It was the DatabaseJoiner. Jennifer used it to join the features to the revoked_licenses table in the database, using the business license number as the key. The join created multiple streams in Jennifer's workspace when it split the features into Joined and Unjoined streams:

DatabaseJoiner

Jennifer connected the Unjoined port to the writer feature type because she wanted to retain features without a revoked business license.

If you didn't guess correctly, try to add the DatabaseJoiner now and see if you can configure it properly. Read the hints in the last exercise and the transformer documentation if you need help. Part of learning to use new transformers is trying things out for yourself; hopefully, you can add it successfully. If you get stumped, load the starting workspace for this exercise and inspect the DatabaseJoiner's parameters. Ensure you understand how it is configured before proceeding.

Multiple Solutions

Like most things in FME, this challenge has multiple solutions. The DatabaseJoiner is the most efficient solution, but you might have found a different transformer.

FeatureMerger or FeatureJoiner

The best runner-up solution is a PostGIS or PostgreSQL reader and a joining transformer. The FeatureMerger and FeatureJoiner work in this case. You can read the revoked_licenses table, join it to the source data, and use the unjoined ports to get the valid licenses. That's not a wrong solution, but it doesn't meet the goal of doing this all without adding an additional reader.

AttributeFilter

You could add an AttributeFilter and manually set it to remove the four revoked license values from the data. However, this approach has two problems:

  1. If the underlying data changes, you must update the workspace. The filter values in the AttributeFilter are hard-coded. You would have to edit this transformer to update the workspace to filter out newly revoked licenses, which would make the workspace inflexible.
  2. You must still add a PostGIS or PostgreSQL reader and read the revoked_licenses table. The goal here is not to have to add an additional reader.
    1. While it's not an issue in this scenario because the revoked_licenses table is small and only contains necessary data, using a reader would negatively affect workspace performance if you read from a larger table. FME would read the entire table and then look for matches in the source data. The DatabaseJoiner reads only the data needed for the join, making it a more efficient solution.

Tester or TestFilter

These filtering transformers have the same issue: if you want to use them alone to filter out the revoked licenses, you must hard-code the revoked license numbers into the test. There are more sustainable long-term solutions.

Scenario

Jennifer

For the next step in her workspace, Jennifer wants to add another filter to her data before FME writes it out. She needs to remove Arcu Ltd's business license. She can use a Tester transformer to do that.

1) Open FME Workbench

2) Add a Tester

Adding a Tester transformer

3) Configure Tester

Logic Left Value Operator Right Value
NOT company = Arcu Ltd

Selecting from cached values

If you don't see values here, ensure you have both:

  1. Connected the DatabaseJoiner's Unjoined port to the Tester's Input port
  2. Run the workspace to get a data cache on the DatabaseJoiner

4) Run Tester

5) Inspect Filtered Data

We should inspect the Tester to ensure the correct features are filtered out.

Filtered data

6) Inspect Final Results

Now that the workspace is complete,

View Written Data button

Viewing the new OBJECTID column in Table View

Optional Challenge

Jennifer notices a problem. There is now a _matched_records attribute on her features. She doesn't want this to be written to the final data.

Follow along with Jennifer’s steps above, and then use one of the techniques covered earlier in the course to ensure that _matched_records is not written. You have a few options:

For an extra challenge, find and add a transformer to order features alphabetically by the value of last_name.

Learn More

See the Tester documentation for more information.

Leave Us Feedback on This Lesson